feat(progress-bar): add recipe and tokens#31087
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ShaneK
left a comment
There was a problem hiding this comment.
Looking good! Just a couple things I noticed but I could be off base
| }, | ||
|
|
||
| IonProgressBar: { | ||
| height: 'var(--token-scale-100, var(--ion-scaling-100))', |
There was a problem hiding this comment.
var(--token-scale-100, var(--ion-scaling-100)) wraps a --token-* variable I couldn't find defined anywhere in the repo. Same on lines 532 and 538 with --token-round-xs and --token-rectangular-xs. Is this intentional scaffolding for the ionic modular work? If not, the other component entries in this file (IonChip, IonSpinner, IonItemDivider) reference --ion-* directly, so maybe this should too? Not sure.
There was a problem hiding this comment.
Ah, I meant to add a comment here.
You're right that --token-* variables don't exist in this repo. They're defined in the OS project. The intent was to make it easier for the components team to adopt the Ionic token file in the future by referencing --token-* first with --ion-* as a fallback. The components team can override values at the token level without having to make as many changes here. If we approve this change, I plan to go back to the others and add the --token-* variables through a different PR. I figured if it gets denied, then no need to do that extra work. 😅
There was a problem hiding this comment.
Don't we plan to have them override all of these? Like they will redefine this, changing both variables:
height: 'var(--token-space-100, var(--token-scale-100, 4px)',There was a problem hiding this comment.
I'm hoping that they don't plan on overriding them especially by having it first check for the --token-*. With the fact that their token system changing frequently, it might be best for us to use --token-* instead of the internal token system. So if the value of --token-scale-100 was 4px but then changes to 6px, they won't have to make an update on this repo because the token is still accurate, just the value changed. This is my reason of why I want to add their CSS variables. Does that answer your question?
There was a problem hiding this comment.
I thought the goal was to not have the themes behave differently from each other. By adding another layer of tokens here we are doing that.
There was a problem hiding this comment.
Understood! Then I'll revert to what we've been doing.
| ); | ||
| } | ||
|
|
||
| :host(.progress-bar-solid) .buffer-circles { |
There was a problem hiding this comment.
When progress-bar-solid is set, the render function applies ion-hide (display: none !important) to the parent .buffer-circles-container, so this .buffer-circles rule inside it can't paint. Is the plan to drop the ion-hide toggle later and let CSS handle the hide, or is this rule dead?
There was a problem hiding this comment.
Good catch! 6a19f57
It sounds like we will keep ion-hide but just a different class name.
| class={{ 'buffer-circles-container': true, 'ion-hide': finalBuffer === 1 }} | ||
| class={{ | ||
| 'buffer-circles-container': true, | ||
| 'buffer-circles-container-hidden': finalBuffer === 1, |
There was a problem hiding this comment.
I added this class now so it would be easier to replace when we remove ion-hide.
ShaneK
left a comment
There was a problem hiding this comment.
Looks great, Maria! Awesome work! Just two minor nits, but non-blocking
Co-authored-by: Shane <shane@shanessite.net>
| }, | ||
|
|
||
| IonProgressBar: { | ||
| height: 'var(--token-scale-100, var(--ion-scaling-100))', |
There was a problem hiding this comment.
Don't we plan to have them override all of these? Like they will redefine this, changing both variables:
height: 'var(--token-space-100, var(--token-scale-100, 4px)',Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
Issue number: internal
What is the current behavior?
Component styles for
ion-progress-barare fragmented across multiple files (native andionic). Themdandiosthemes rely on the native styles. Developers were restricted to those themes and how those themes structured the logic and styles.What is the new behavior?
progress-bar.scssfile that consumes CSS variables, ensuring a single source of truth for component logic.IonProgressBartype and tokens to use an element-first hierarchy ({type}.{element}.{state}, e.g.,determinate.progress.default.background). This provides predictability and consistency with the rest of the system.progress-bar.interfaces.tswith reusable types for the recipe and config.ios,md, andionictheme files.roundandrectangularshape variants with per-theme defaults (roundforiosandionic,rectangularformd).buffer = 1), including separate rules for the buffer bar and buffer circles.progress-bar-type-determinate/progress-bar-type-indeterminate) to prevent cross-type style bleed.--backgroundand--progress-backgroundwith a structured set of semantic variables (e.g.,--ion-progress-bar-determinate-progress-default-background).Does this introduce a breaking change?
This PR introduces breaking changes to how
IonProgressBaris styled.Migration Path:
Token Updates: Update any custom theme configurations to match the new nested structure.
CSS Variable Replacements:
--backgroundand--progress-backgroundhave been removed. Use the new token structure instead:--background→IonProgressBar.determinate.buffer.bar.default.background(or the indeterminate equivalent)--progress-background→IonProgressBar.determinate.progress.default.background(or the indeterminate equivalent)If per-component customization is needed, the CSS variables can be used directly (e.g.,
--ion-progress-bar-determinate-progress-default-background).Host class names: The type classes on the host element have been renamed to include the prop name:
.progress-bar-determinate→.progress-bar-type-determinate.progress-bar-indeterminate→.progress-bar-type-indeterminateTheme classes: Remove any instances that target the theme classes:
ion-progress-bar.md,ion-progress-bar.ios.Other information
Previews:
Previews: